home *** CD-ROM | disk | FTP | other *** search
/ AmigActive 25 / AACD 25.iso / AACD / Magazine / Online / QMail / docs / RFCMXPS < prev    next >
Encoding:
Text File  |  1997-04-15  |  5.2 KB  |  123 lines
  1. The Mail Exchanger Protocol Switch (MXPS)
  2. D. J. Bernstein, djb@pobox.com
  3. 19970201
  4.  
  5.  
  6. 1. Introduction
  7.  
  8.    Mail messages today are transferred through the Simple Mail Transfer
  9.    Protocol (SMTP). One can imagine other protocols that achieve the
  10.    same results as SMTP but that, for example, use the network more
  11.    efficiently.
  12.  
  13.    The Mail Exchanger Protocol Switch (MXPS) lets other protocols
  14.    compete with SMTP. A receiver can announce its support for another
  15.    protocol while operating properly with MXPS-ignorant senders. A
  16.    sender can check for support, with no overhead, while operating
  17.    properly with MXPS-ignorant receivers.
  18.  
  19.    All receivers must support SMTP, i.e., must be able to receive
  20.    messages via SMTP. Similarly, all senders must be able to send
  21.    messages via SMTP.
  22.  
  23.  
  24. 2. The protocol switch
  25.  
  26.    MXPS abuses the preference field of MX records. A protocol is
  27.    assigned to each possible preference.
  28.  
  29.    SMTP is assigned to preferences 0 through 10000.
  30.  
  31.    The initial MXPS experiment will involve preferences between 12800
  32.    and 13055 inclusive. These preferences are sliced into 16 portions:
  33.  
  34.       12800, 12816, 12832, 12848, 12864, ..., 13040: slice #0 (SMTP)
  35.       12801, 12817, 12833, 12849, 12865, ..., 13041: slice #1 (QMTP)
  36.       12802, 12818, 12834, 12850, 12866, ..., 13042: slice #2
  37.       ...
  38.       12815, 12831, 12847, 12863, 12879, ..., 13055: slice #15
  39.  
  40.    Preferences in slice #0 are assigned SMTP. Preferences in slice #1
  41.    are assigned the Quick Mail Transfer Protocol (QMTP). Preferences in
  42.    the remaining slices may be assigned protocols in the future.
  43.  
  44.    A receiver must support the protocol assigned to its preference. More
  45.    precisely, if an MX record points to domain D, and the MX preference
  46.    is assigned protocol P, then every host listed as an A record for D
  47.    must support protocol P.
  48.  
  49.    When a sender, following the procedure outlined in RFC 974 (and
  50.    modified by RFC 1123), attempts to deliver a mail message as
  51.    specified by that MX record, it may use protocol P instead of SMTP.
  52.    If it does not support protocol P, it may treat the attempt as a
  53.    temporary failure and go on to the next MX record. However, the
  54.    sender must not skip every MX record.
  55.  
  56.    MX records must never use unassigned preferences. A sender may treat
  57.    an unassigned preference as referring to SMTP.
  58.  
  59.    Example: 
  60.  
  61.       A.EXAMPLE.ORG  IN  MX  12801  A.EXAMPLE.ORG
  62.       B.EXAMPLE.ORG  IN  MX  12801  A.EXAMPLE.ORG
  63.                      IN  MX  12816  C.EXAMPLE.ORG
  64.  
  65.    A sender with a message for A.EXAMPLE.ORG will try A.EXAMPLE.ORG by
  66.    QMTP. If it does not support QMTP, it will try SMTP instead. Note
  67.    that A.EXAMPLE.ORG must support both QMTP and SMTP.
  68.  
  69.    A sender with a message for B.EXAMPLE.ORG will try A.EXAMPLE.ORG by
  70.    QMTP, then C.EXAMPLE.ORG by SMTP. If it does not support QMTP, it may
  71.    try SMTP instead of QMTP, or it may skip A.EXAMPLE.ORG.
  72.  
  73.    Some of the above requirements might be violated if current
  74.    MXPS-ignorant domains use any preferences above 10000. Mail could be
  75.    unnecessarily rejected if any existing MXPS-ignorant domains have a
  76.    best-preference MX above 10000. I do not know any examples of such
  77.    domains.
  78.  
  79.  
  80. 3. Protocol requirements
  81.  
  82.    MXPS operates purely at the link level. It does not change the
  83.    fundamental nature of Internet mail.
  84.  
  85.    The function of a mail transfer protocol is to transmit a message, as
  86.    described below, together with an envelope sender address and one or
  87.    more envelope recipient addresses.
  88.  
  89.    A recipient address is a sequence of characters---i.e., nonnegative
  90.    integers---including an ASCII @ (64). It is parsed as box@dom, where
  91.    dom does not contain an @. The interpretation of box is up to the
  92.    hosts listed as MX records for dom. A sender address may contain an
  93.    @, in which case it is also of the form box@dom; or it may be a
  94.    special address, such as the empty string.
  95.  
  96.    A mail message is structured as a sequence of lines. A line is a
  97.    sequence of characters. Every mail transfer protocol must be able to
  98.    transmit all sufficiently short boring mail messages. A boring mail
  99.    message is one where (1) no line has more than 80 characters and (2)
  100.    each character is either 9 or between 32 and 127 inclusive. Note that
  101.    RFC 1341 defines a mechanism for encoding a message with characters
  102.    between 0 and 255 inclusive as a boring mail message of similar
  103.    length.
  104.  
  105.    The receiver must indicate, for each recipient address, either
  106.    acceptance, permanent rejection, or temporary rejection of the
  107.    message. Acceptance means that the receiver has taken responsibility,
  108.    in the sense of RFC 1123, section 5.3.3, for delivering the message
  109.    to that recipient. Rejection means that the receiver will not deliver
  110.    the message to that recipient.
  111.  
  112.    Mail transfer protocols may vary in many details, such as line
  113.    encodings, the means of expressing acceptance or rejection, the
  114.    maximum number of allowable recipients per envelope, the encoding of
  115.    envelope addresses, the nature of optional protocol extensions, etc.
  116.  
  117.  
  118. 4. Security considerations
  119.  
  120.    MXPS does not change the following facts: An attacker who can subvert
  121.    the Domain Name System can steal or forge mail. An attacker who can
  122.    subvert TCP/IP can also steal or forge mail.
  123.